Field of the Invention
Embodiments of the invention relate to hydrocarbon reservoir production and, more specifically, to methods, systems, and non-transitory computer-readable medium having computer program stored therein to simulate fluid flow within hydrocarbon reservoirs.
Description of the Related Art
Simulated models of hydrocarbon reservoirs may be used to simulate fluid flow of hydrocarbons or other fluids within a reservoir. These hydrocarbon reservoir simulation models may require a large amount of data, however, as input during the simulation process, which may consist of one or more hydrocarbon reservoir simulation runs. That is, a real hydrocarbon reservoir or real hydrocarbon field may be modeled using a mathematical representation of the real reservoir or field. The resulting reservoir model, for example, is an approximation of reality. The accuracy of these models may depend on the available data, the physics of the real reservoir captured by the reservoir simulation, and engineer insight and availability. As more data becomes available, a new reservoir model may be constructed and an older model archived. Each model that is constructed is a representation of the real reservoir and is part of a hydrocarbon reservoir simulation study with a specific objective or goal. A hydrocarbon reservoir simulation study, for example, may include one or more simulation runs (sometimes called “jobs”). That is, within a reservoir study, a model may be built then iteratively modified so as to create hundreds of model versions until a final reservoir model is found that meets the objective of the study. Model versions may also be described, in some circumstances, as simply “models.” Further, model versions may also be described as “jobs” because they are submitted to a job scheduling system. Similarly, model versions may be described as “runs” because they run on a cluster. Each model version frequently has only one job and is only processed (i.e., run) once, although exceptions may occur when a run fails, when a need to reproduce results exists, or when using different simulation versions.
Furthermore, hydrocarbon reservoir simulation models may produce a large amount of data as output of each hydrocarbon reservoir simulation run. Data associated with each hydrocarbon reservoir simulation model may be stored separately, however. That is, each model may have its own set of stored data, including input and output data. In some cases, two or more models may each store the same data. For example, some of the output data of two different hydrocarbon reservoir simulation runs may be the same when each hydrocarbon reservoir simulation run is associated with the same hydrocarbon reservoir. In addition, two models may require the same input data, for another example. In both examples, each hydrocarbon reservoir simulation model may nonetheless be associated with a separate copy of the stored data. Consequently, a hydrocarbon reservoir simulation process may produce and consume large amounts of data. Over the past ten years, for example, data storage requirements have grown exponentially.
Two hydrocarbon reservoir simulation models or multiple projects may require the same hydrocarbon reservoir simulation input files, for example. As illustrated in FIG. 1A, for example, many hydrocarbon reservoir simulation models may each have their own binary data simulation files 61, ASCII data simulation files 62, and other data simulation files 63. That is, hydrocarbon reservoir simulation model 1 65, hydrocarbon reservoir simulation model 2 66, hydrocarbon reservoir simulation model 3 67, and other hydrocarbon reservoir simulation models through hydrocarbon reservoir simulation model X 68 may each have an associated set of binary data simulation files 61, ASCII data simulation files 62, and other data simulation files 63. In this example, binary input files 61 are repeated. Consequently, each hydrocarbon reservoir simulation model may have its own set of data even when some simulation files in different sets may be the same.
Two main business workflows may exist in hydrocarbon reservoir simulation fields: (1) history-matching studies and (2) prediction studies. History-matching hydrocarbon reservoir simulation studies, as will be understood by those skilled in the art, may include performing hydrocarbon reservoir simulation runs to calibrate a given hydrocarbon reservoir simulation model. For example, after comparing results of the hydrocarbon reservoir simulation runs to observed or predicted data, the hydrocarbon reservoir simulation model may be modified as necessary to produce more accurate results. Prediction hydrocarbon reservoir simulation studies, on the other hand, may include performing hydrocarbon reservoir simulation runs to predict future fluid flow in the hydrocarbon reservoir, for example. An entity may perform a significant number of each type of hydrocarbon reservoir simulation study. As an example, an entity may conduct around 20 history-matching hydrocarbon reservoir simulation studies and over 1,000 prediction hydrocarbon reservoir simulation studies annually. In a single year, furthermore, these studies may amount to more than 100,000 hydrocarbon reservoir simulation runs. In these studies, hydrocarbon reservoir simulation runs may evolve incrementally based on manual changes by simulation engineers, who may duplicate hydrocarbon reservoir simulation input data based on previous hydrocarbon reservoir simulation runs and perform slight modifications. In addition, hydrocarbon reservoir simulation runs may evolve responsive to automatically utilizing assisted history-matching and optimization packages that deploy a variety of optimization algorithms to maximize a set objective function, e.g., minimize history match error, maximize net present value (NPV), maximize oil recovery, etc. As a result, output data generated by a hydrocarbon reservoir simulator, as will be understood by those skilled in the art, may tend to have a lot of duplication due to minimal changes that may be introduced by the user, such as, for example, static and dynamic history data and geometrical information.
For example, Applicant has recognized that more than three-quarters of an entity's storage capacity may be dedicated to duplicated data, in some circumstances. An example is illustrated in FIG. 1C, which depicts the size in storage of files, for example. In this example, approximately 900 history-matching hydrocarbon reservoir simulation runs over the course of three months have produced approximately 2,000 files that require 8,076 GB of disk space. Of this data, however, only 1,976 GB correspond to unique files, whereas the other 6,296 GB correspond to duplicated files. That is, as is further illustrated in FIG. 1D, approximately 76.1% of the entity's stored data, as measured in gigabytes, is dedicated to duplicated data 98 in this example. That is, the percentage of unique data 97 to duplicated data 98 is depicted in FIG. 1D, for example.
A simulation engineer may manually manage multiple hydrocarbon reservoir simulation models by duplicating all input data for a hydrocarbon reservoir simulation model that is required for both history-matching and prediction hydrocarbon reservoir simulation studies. For example, a method to perform a hydrocarbon reservoir simulation run may include user interaction 50 and simulator action, as illustrated in FIG. 1B. For example, after a start 51, user interaction 50 may include collecting simulation data 52, such as hydrocarbon reservoir description data, then building a hydrocarbon reservoir simulation model 52. A user may then choose to either select a hydrocarbon reservoir simulation model 54 or duplicate a hydrocarbon reservoir simulation model 55. If the user duplicates a hydrocarbon reservoir simulation model 55, the user may then select a hydrocarbon reservoir simulation model 54. After selecting a hydrocarbon reservoir simulation model 54, a user may choose whether to run the hydrocarbon reservoir simulation model 56, i.e., whether to perform a hydrocarbon reservoir simulation run of the selected hydrocarbon reservoir simulation model. If the user chooses not to run the hydrocarbon reservoir simulation model 56, the user may then modify the selected hydrocarbon reservoir simulation model 57. After modifying the hydrocarbon reservoir simulation model 57, the user may then again select a hydrocarbon reservoir simulation model 54. For example, the user may select the modified hydrocarbon reservoir simulation model. If the user chooses to run the hydrocarbon reservoir simulation model 56, the hydrocarbon reservoir simulation run may be started 58 and may produce some output 59, such as, for example, simulation files.
Data may be “de-duplicated,” for example, by combing through existing data files manually to identify duplicate data. Duplicate data may be deleted, and file links may be used instead. Further, using file links to optimize storage may be a shared storage implementation in Linux file systems. But deduplication as part of a backup, sync, or cleanup process as a solution may be time-consuming because it may require investigating all files in both primary and secondary file systems.